Hello @richardfontana, I'll do my best to understand and respond:

it seems that vcr had a substantial number of contributions when it was under the MIT license aside from the maintainers listed in the LICENSE file ...
Also (not knowing the history of this project) it looks like review of the license change was requested from @myronmarston who I gather was the original developer of the project but did not appear to respond in that issue

Yes! vcr has a long and varied history with many people contributing. Yes, Myron was the original creator of the library, but he had handed it fully to me some time ago.

To be clear, the MIT license ... permits derivative works to be placed under more restrictive licenses, but the original license text can't be removed...

As far as I know, we haven't removed the original license text. It's still visible at that point in the history.

Obviously not wanting to speak for Richard, but I believe he's trying to communicate that, if his 3 assumptions hold true, so long as those contributions are part of the codebase, you are in violation of the MIT license if you distribute those contributions without the text of the MIT license. The master branch of your codebase contains their copyrighted contributions but does not contain the MIT license those contributors licensed their contributions to you under.

Ah, I was confused by the mention of Myron since I own this repository in totality.

Understand that while I'm not a lawyer there are lawyers who are talking about this currently, so it's an ongoing discussion. The real important question is: Can someone sue me for creating a new distribution (to ruby gems) with to a more restrictive license? Here are some of my opinions based on research, but with the context that I am not a legal expert:

1. "branches" aren't a codified construct in copyright law, but I think it's reasonable to consider the git repository as a distribution of the code. It contains the old license and code in the git history, so we're covered no matter what there.
2. According to the MIT license allowed to sublicense, which in my opinion covers this case (based on the legal definition of sublicense).
3. The MIT license and code was created as the copyright of Myron. The github distribution and rubygems distributions were handed to me (after copious bug fixes!).
4. Contributors own the changes they wrote in their distribution, no doubt.

Which leaves us with the important questions:

1. Is the source in the repository that someone submitted a pull request for and was eventually copied with their consent now mine?
2. Is the source I copy from github into rubygems mine?
3. Does this count as a sublicense?

I'm not so sure on 1 & 2, because it has frustrating implications for Github, but I do think this is a valid case where the answer to 3 is "yes". I have not removed rights, I have simply added a new limitation on who can be given rights.

Even if the answer to 3 is "no", the github can remain the same but for the rubygem distribution we have to take into account two factors:

1. Will anyone take me to court to assert their rights?
2. How do I rollback a distribution that I had no legal right to make? I'd have to get special permission from rubygems.org for one. That'll be painful.

The issues #792 and #797 don't show any indication that anyone other than the maintainers agreed to this license change

@krainboltgreene I have seen another ruby gem change license and they had attempted to contact all contributors to the project to get their approval: prawnpdf/prawn#625

Using the github repo contributors for vcr shows 125 contributors: https://github.com/vcr/vcr/graphs/contributors

It might be hard to know if all of those contributor's contributions are still in master but it's an easier way to cover yourself.

EDIT: Contributors shows 125 contributors but when you click the link above, it only seems to show 100.

@krainboltgreene Thanks for your reply. I'm not a lawyer, and I don't pretend to know everything about licensing. I did work for a certain Boston-based communist software narcosyndicate for a number of years, so what follows is the understanding they imparted upon me.

Every time you commit to Github, you're creating a distribution - I can go and download from Github the code at a certain revision. Every time you release a ruby gem, you're creating a distribution. It's not sufficient to say "at some particular commit in time, the license was made available" to meet the conditions of the license.

The MIT license includes:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

When a community member contributes to your codebase, they're doing so under that license. They're licensing you the code in order to include in the collective work. While the MIT license permits you, the aggregator of the work, to re-license it under a more restrictive license, you're still bound by the terms of the license your contributors issued to you - that's why larger projects insist on something like a "contributor license agreement" that waives certain contributor's rights under copyright for things like relicensing without consent.

If you continue to include copyrightable contributions from other contributors in your code without such an agreement, my understanding is you're bound to the terms under which those contributions were made, in this case the MIT license. Continuing to distribute the collective work without the MIT license text included would arguably put you in breach of their copyright, and any of your users who redistributed your code would similarly be in breach of their copyright.

Again, I'm not a lawyer, but my understanding is that to be in compliance, you have three options: 1) discard contributions from contributors who have not actively consented to your relicensing and re-implement them in a clean-room fashion; 2) collect the consent of those contributors to relicense their contributions to you under the new licensing scheme; or 3) include the text of the MIT license in your codebase so long as those contributions continue to be part of your distribution.

ffi also went through the effort of asking all past contributors. Theirs was interesting because it went from BSD -> LGPL -> BSD, so they asked all contributors during the LGPL time frame - ffi/ffi#288

@krainboltgreene I think what you are saying is that vcr is in compliance with all those past MIT license grants because a copy of the MIT license is still present in the git history of the project. I would say this is not currently a standard interpretation of the MIT license (which says "this permission notice shall be included in all copies or substantial portions of the Software."). And anyway isn't it true that the gem itself does not contain a copy of the MIT license in this sense? Imagine if I forked vcr 5.1.0 and put my changes in my fork under the MIT license - which I believe I can do just as you can put 5.1.0 under the Hippocratic License. If I then deleted the Hippocratic License and only included a copy of the MIT license, wouldn't you be concerned that this would be misleading? (Or to keep it in terms of your view of this as a sublicense, suppose I put my fork under a derivative of the Hippocratic License that prohibits distribution. It raises the same issue.)

Regarding your questions,

Is the source in the repository that someone submitted a pull request for and was
eventually copied with their consent now mine?

Not yours in the sense that it is not owned by you. It was licensed to you under the MIT license.

Is the source I copy from github into rubygems mine?

Not yours to the extent that it consists of code written by other people and licensed to you under the MIT license.

Does this count as a sublicense?

I think it can be understood as a sublicense, yes, though I'm not sure if that's the best way to look at it. But the MIT license conditions sublicensing on "this permission notice shall be included in all copies or substantial portions of the Software", and standard practice is to assume that means you have to include the original license text in the sublicensed version - as @j00bar says, in the master branch, not hidden in the commit history.

Will anyone take me to court to assert their rights?

I mean, most likely not. But it's sort of about doing the right thing (both in terms of meeting the expectations of past contributors and making things clear to, and compliant for, users downstream), which I would think the vcr project would care about given that they decided to move to a license that tries to address matters of ethics.

How do I rollback a distribution that I had no legal right to make? I'd have to get special
permission from rubygems.org for one. That'll be painful.

I don't know, but you could at least fix this going forward for future versions?

So two things I've noticed about the discussion so far:

1. The idea that no contact was done or that github is a means of contact. There's no need to discuss this here nor is there a need to discuss how or who to contact.
2. No contributors have come into the discussion yet (as far as I can tell), I'd love to see those that have contributed weigh in.

@j00bar Frankly, while a lot of what you've said makes sense (except the contributor licensing to me) if it was true the open source community would have a lot of questions to answer and things to do should someone ever sue. Are there any judgements you can reference to back up these claims?

@richardfontana

And anyway isn't it true that the gem itself does not contain a copy of the MIT license in this sense?
The gem does in fact reference a license.

Not yours in the sense that it is not owned by you. It was licensed to you under the MIT license.

You've not actually answered the question, but repeated what I already said: The code they wrote is theirs, but by merging I effectively wrote it to the repository. They may be identical source, but who owns the one in vcr?

Not yours to the extent that it consists of code written by other people and licensed to you under the MIT license.

That doesn't make sense. If someone make a change where it shifts every line down by one and I merge it in, do they now own all the code and have simply licensed it to me?

not hidden in the commit history

This phrase in particular is interesting. Do you have any legal research that suggests commit history is hiding?

But it's sort of about doing the right thing (both in terms of meeting the expectations of past contributors and making things clear to, and compliant for, users downstream), which I would think the vcr project would care about given that they decided to move to a license that tries to address matters of ethics

Try to keep the discussion clear of suggesting the vcr team is doing something unethical. We released a new version with a license change. What we're discussing here is if that act is "compliant" (for whatever definition) with the MIT license.

(Someone said I came off as testy in the comment, but I want to be clear I'm glad vcr be the onus for this conversation. Worst case scenario I(?) get sued, which is not a big deal for me.)

Is @richardfontana a contributor? Is there an active issue here or is this theoretical?

I don’t think non lawyers talking about what they think lawyers might think over a GitHub issue is terribly helpful. There is an ethical source working group for people interested in exploring this further. I don’t think this is the place for this conversation.

Let’s close this issue.

I don't believe Mr. Fontana is a contributor, but he is certainly an attorney - his Wikipedia page suggests he is currently retained by Red hat, he was an attorney at the Software Freedom Law Center, and, along with Richard Stallman and Eben Moglen, he was one of the principal drafters of the GPL version 3. While he rightly stated in at the outset that this is not legal advice, there are very few humans on the planet who know more than he does about Free Software licensing.

My non-lawyer understanding of copyright on this matter is that if a user contributes a substantive piece to the combined work (a contribution of a blank line isn't substantive and therefore isn't copyrightable - typo fixes, and trivial fixes are likewise non-substantive), then any combined work which continues to include their substantive piece is using that substantive piece under license - in your case, under the MIT license. According to the plain text of the license, you must include the license text with the software so long as it includes their substantive contributions. You don't own them - they are licensed to you.

Will you get sued? I don't know - probably not. But is that the real litmus test? You're violating your contributors copyrights - that's wrong and completely against the ethos of the free/open-source community. Trust is all we have binding us together. For my part, I'm writing on this less as if we were on /r/legaladvice and more as if we were on /r/AmITheAsshole. And in this case, if you move forward with this change to vcr in this manner, knowing you're violating the rights of your contributors by doing so, YTA. If I were a contributor, I'd really think twice before submitting a PR when I knew for a fact the maintainers felt entitled to take my work and relicense it without my consent.

You've not actually answered the question, but repeated what I already said: The code they wrote is theirs, but by merging I effectively wrote it to the repository. They may be identical source, but who owns the one in vcr?

Merging contributions from other people does not erase their copyright. Their copyright persists. You might have an extra copyright based on the merging itself (beyond what you yourself contributed -- think of the editor of an anthology).

Not yours to the extent that it consists of code written by other people and licensed to you under the MIT license.

That doesn't make sense. If someone make a change where it shifts every line down by one and I merge it in, do they now own all the code and have simply licensed it to me?

No, because copyright only arises from things that are sufficiently original and creative. (It's possible some of the many community contributions to vcr are too trivial to be copyrighted in the first place.)

not hidden in the commit history

This phrase in particular is interesting. Do you have any legal research that suggests commit history is hiding?

Either you're in compliance with the MIT license or not -- I admit there is a question about that, and I'm asserting that there's a longstanding community practice around open source to the effect that merely having a copy of a license like the MIT license in the commit history is not good enough to meet the MIT license's requirements. I'm giving a policy reason for why that community practice is the better position -- or why, if you disagree with that, you should at least put users of the gem on notice that there's a lot of code in there that is under a license with obligations they have to comply with that is not immediately visible. The MIT license obligations don't go away as long as those pre-Hippocratic vcr contributions continue to be present in the master branch. But normally no one would expect to dig into the commit history to find them. All applicable license conditions should be visible in the master branch if the license has a notice requirement -- as the MIT license does (and the Hippocratic License as well, which is based on the MIT license).

Is @richardfontana a contributor? Is there an active issue here or is this theoretical?

I'm not a contributor, but many developers at my company use vcr. The requirements of the MIT license from past contributors apply to anyone using vcr, not just the maintainers, so it's not theoretical.

So users and downstream distributors would also be violating the contributors' copyright? 😕

So users and downstream distributors would also be violating the contributors' copyright?

Yes, under a straightforward interpretation of the MIT license. It's probably really low risk but compliance with open source licenses isn't just about mere risk management. Those past contributors aren't likely to care, but by not complying with the MIT license, vcr currently looks as though all those past contributors must have agreed to a wholesale relicense from MIT to Hippocratic, when in fact none of them were consulted other than the maintainers listed in the copyright notice. (Again to be clear, they don't have to agree to anything, since the MIT license is so permissive, but the one thing it does require is that the original license text be kept intact.)

vcr currently looks as though all those past contributors must have agreed to a wholesale relicense from MIT to Hippocratic

For an attorney that seems like an extreme stretch to make. I mean in this very thread, the only discussion so far about the issue brought up, zero people assume I did any due diligence (regardless of if true or even needed).

Okay. Have you obtained the consent of all of the contributors who have made substantive contributions to relicense their contributions from MIT to Hippocratic?

The MIT license permits anyone to take MIT-licensed code and even use it in a proprietary project without open-sourcing anything. A good point has been made about removing the MIT license itself from a project is a no-no, but what about leaving the MIT license there and adding a Hippocratic clause?

Secondly, MIT permits sublicensing. Anyone know what needs to be done for that to be triggered, such as renaming a project, or creating a "new" repo that simply imports and exports VCR, where that new "wrapper" repo is licensed using the Hippocratic License?

Can a new version of a project not sublicense the old version, for example?

EDIT: looks like it can't, but that "wrapping" an MIT-licensed project would indeed constitute sublicensing, though it may need to be a different project and not just a parent folder? https://softwareengineering.stackexchange.com/a/189704

Seems pretty clear to me. I think it's an honest mistake, and that stuff happens in the complicated world of software licensing.

There's an easy, clear solution: add the MIT notice back in, cut a new release. It's still under Hippocratic License, but now it's above-board. If I were you, I'd yank all previous hippocratically-licensed versions from RG, otherwise RG will probably do it for you because they don't want to distribute material that violates IP law.

@richardfontana When you re/double/sublicense/create a derivative work (did we decide on a term for what's happening here?) in this way, how do you include the prior notice while still making it clear that that license only applies to the old portions of the work? "Contributions made prior to or (C)..." and then just include the rest?

@nateberkopec before seeing your comment I just submitted #805 which is one way I'd suggest doing it. I can't comment on what to do about RG but hard to see how anyone could reasonably complain if the issue is fixed in the master branch.

@j00bar: That's not germane to the discussion at hand nor to my point.

@nateberkopec: If it were "pretty clear" there wouldn't be a discussion.

otherwise RG will probably do it for you because they don't want to distribute material that violates IP law.

lol

There's an easy, clear solution: add the MIT notice back in, cut a new release.

That's a solution to a problem that does not exist. A release has already been made with the license property set to the new license shortname. The license itself has changed twice!

vcr has never shipped with a license file and I'm pretty sure I'm the one who started using the license property. Making a new release wouldn't change the fact that prior distributions supposedly aren't compliant with the MIT license. Prior to that I had also changed the year without notifying contributors either.

Further, I remain unconvinced that the change we made isn't compliant with the MIT license requirements. I firmly stand my ground after this discussion so far that this is a sublicense and therefore no consent is required from contributors.

Further, in all the cases presented so far in this discussion the "consent outreach" activity has been shaky at best at being a solution:

1. The license changes were relicenses
2. It was a bunch of github comments. Some of those users are banned, their accounts no longer linked to that comment, with no authorship or authority bestowed.

Further, (as per my rejection notice) the posit solution of re-adding the license to the repository seems to be on equally shaky ground: I am to believe that if someone were to have an issue they would be fine with

Some portions of vcr are covered by the following copyright and license notice:

Which brings me to my final point: Even if we conceded that this was worthy of reaching out for consent, determining who to reach out to becomes a nightmare that frankly isn't worth anyone's time:

0. What counts as a considerable enough contribution to be worth asking for consent to change the license?
1. Does that considerable contribution still exist in a way that is considerable?
2. What about if our only audit of history has been rewritten at any point in time?
3. Did they have the right to even copyright their change?
4. Are they even reachable?
5. Are they able to communicate consent in a fashion that would pass muster in a legal battle?
6. For those that don't consent to the license change, and I still want to go ahead, how do I denote what code is under what license?
7. If I can't denote ownership easily enough, I must remove the change, and the change is intermingled with other change then surely I must also replace the code in which case what constitutes "good enough"?
8. If we've never shipped the license with the gem, do I now go yank 68 gems?

Luckily I think we're well within our rights to do what we did and I'm willing to deal with any challenge to this.

@krainboltgreene I'm sorry if I made you feel like you had to defend yourself.

If it were "pretty clear" there wouldn't be a discussion.

I was only attempting to summarize the discussion above. I agree that beforehand, lay understanding of software licensing really wouldn't provide any clear direction. I think @richardfontana laid out a very clear and cogent case.

That's a solution to a problem that does not exist.

I think you may have misunderstood me? I'm not saying to re-release the project under MIT. I'm saying put the license back in the license file, say "previous contributions are licensed under...", and you're done.

therefore no consent is required from contributors.

I didn't say you needed that, @richardfontana didn't say you needed that. You just need to put the license file back in the project, because every contribution made prior to that license change was made under that license. If you don't want to keep the license in the project, you do need consent from contributors. That's all. You can keep doing everything else you've done. You just need the license file in distributed copies of VCR, as in #805.